[00:01.880 --> 00:07.820]  Hello, my name is Arkady Litvinenko. I'm a lead penetration tester in a Russian company that
[00:07.820 --> 00:16.760]  has the name Bizon. Also, I'm one of the organizers of the Russian conference of ZON in Moscow,
[00:17.240 --> 00:27.540]  and one of the organizers of CTF ZON competitions, CTF, and also a co-author of DEFCON CTF.
[00:27.540 --> 00:37.020]  So, today we will talk about online banking security. And firstly, among projects on my
[00:37.020 --> 00:44.480]  job, I have a lot of security audits of different online banking applications. And during these
[00:44.480 --> 00:52.460]  projects, I met and we met a lot of different vulnerabilities and other interesting things.
[00:52.460 --> 00:58.340]  So, in this presentation, I want to share with you some experience that I got and some interesting
[00:58.340 --> 01:09.040]  things. And so, this talk will be interesting for offensive and defensive specialists that
[01:09.820 --> 01:17.240]  work with online banking applications. And also, it will be interesting for developers who
[01:18.400 --> 01:23.420]  work with online banking and who is trying to make it safer.
[01:25.100 --> 01:32.000]  But I tried to make this presentation with a growing difficulty level. So, I hope everyone
[01:32.000 --> 01:37.300]  can get something new from this presentation and get something interesting from this presentation.
[01:37.300 --> 01:41.560]  So, let's talk about the structure of this presentation, about what we are going to talk
[01:41.560 --> 01:51.040]  about. So, firstly, we will talk about differences, about remote banking and online banking, and what
[01:51.040 --> 01:57.560]  is remote banking and what is online banking. We will talk about web banking, mobile banking,
[01:57.560 --> 02:04.620]  what differences between them. And after that, we will talk about testing approaches,
[02:05.030 --> 02:14.450]  and how to test the web, mobile, and the server side of mobile banking, and what differences,
[02:14.920 --> 02:21.360]  what guides we can use for this, and we usually use on our projects.
[02:22.450 --> 02:30.960]  And the biggest part of this presentation, it will be vulnerability examples with detailed
[02:30.960 --> 02:40.300]  information, how it works, how to exploit it, and maybe some bad practices of fixing it,
[02:40.300 --> 02:46.420]  of avoiding it, and so on. And also, we will talk about best practices of how to avoid this
[02:46.420 --> 02:53.080]  vulnerability, its vulnerabilities. So, let's begin from the differences. What is remote banking
[02:53.080 --> 03:00.540]  services? It is when the client doesn't need to go to the office to do some actions in bank. For
[03:01.320 --> 03:08.820]  transferring money, for checking the balance of the account, and some other things.
[03:09.060 --> 03:15.620]  So, it can be anything. It can be ATM, it can be call center, it can be SMS banking, and also,
[03:15.620 --> 03:24.120]  it can be a web and mobile banking. For example, we're going to get cash from the account, so we
[03:24.120 --> 03:30.520]  come to ATM, and it is one of the examples of remote banking services. But there is another
[03:31.100 --> 03:37.260]  type of banking services, it is online banking. It is not another, it is part of remote banking
[03:37.260 --> 03:43.920]  services, but it is a thing that we are going to talk about today. So, online banking, it is
[03:43.920 --> 03:50.040]  web banking and mobile banking. So, web banking, it is when you open the website of
[03:51.580 --> 03:55.920]  a bank on the browser and do some actions, and for example, log into your account and do some
[03:55.920 --> 04:02.700]  actions, maybe transfer money, checking balance, and other, and other. So, in mobile, it is totally
[04:02.700 --> 04:09.140]  the same, but you have to download the application to your mobile, and after that, again, you log
[04:09.140 --> 04:19.360]  into the account and do some actions. So, today, we're going to talk about online banking,
[04:19.360 --> 04:25.700]  about web and mobile banking, yeah. And so, we're going to... and all vulnerabilities will be related
[04:25.700 --> 04:34.860]  to these types. So, let's talk about how does it work. It is very, very simple image, yeah,
[04:34.860 --> 04:42.620]  but it is a good image for showing that we're going to talk about. We are not going to talk
[04:42.620 --> 04:47.260]  about infrastructure, our bank infrastructure, about processing, and other very, very complex
[04:47.260 --> 04:54.580]  things. It is magic for us today, and it is like a black box for us. And so, we're going to talk
[04:54.580 --> 05:01.800]  about the server side, about the API, yeah. We're going to talk about the frontend mobile. Frontend,
[05:01.800 --> 05:13.440]  it is something that loads in the browser of clients. So, it can be Angular, it can be React
[05:13.440 --> 05:20.620]  application, it can be HTML with IAC request, but it doesn't work like this now, usually. Maybe
[05:20.620 --> 05:28.960]  there are banks with IAC requests, but I don't know. They didn't meet it. So, mobile, it is
[05:28.960 --> 05:36.940]  totally the same, but mobile application, it is like a custom-made browser. And frontend and mobile,
[05:36.940 --> 05:43.900]  work with API, yeah, with server side. And they send requests to API, and they get requests from
[05:43.900 --> 05:54.980]  API, and they render it, they show UI to the clients, and the clients can work with this UI,
[05:54.980 --> 06:00.500]  and do some actions, maybe clicking the buttons, and other things, and enter maybe some.
[06:00.500 --> 06:12.120]  And so, usually, in banks, API, it is a similar API for the frontend, and the same, sorry, same
[06:12.120 --> 06:18.520]  API for the frontend, and for the mobile. Sometimes, maybe there are differences. Maybe it is
[06:18.520 --> 06:26.780]  split API, so different API for frontend, and different API for mobile. But usually, usually,
[06:26.780 --> 06:35.820]  it is the same. And API, it is like something between... it is an application that
[06:37.620 --> 06:44.260]  helps us to work with bank infrastructure. It has API methods, it has some functionality that
[06:44.260 --> 06:51.140]  can be used by frontend, and that can be used by mobile. And after that, it sends to bank
[06:51.140 --> 06:57.740]  infrastructure, and there is some magic in bank infrastructure. The bank infrastructure is very,
[06:57.740 --> 07:04.980]  very complex. It can be anything. It can be monolith, it can be microservices, yeah. And so,
[07:04.980 --> 07:11.600]  but today, it will be bank infrastructure, and API, it will be server-side for us.
[07:13.080 --> 07:21.120]  And I think it is all that I wanted to say about how does it work. Again, it is very,
[07:21.120 --> 07:27.900]  very simple. And we can't talk more detail, because it needs a lot of time. It is a huge topic.
[07:28.480 --> 07:35.200]  So, testing approaches of server-side and bank infrastructure. Usually, it is... API, it is usual
[07:35.200 --> 07:40.800]  web application, yeah. And bank infrastructure, it is a very complex thing. It is like
[07:40.800 --> 07:45.880]  Zoho with different services. It can be anything. And so, it is
[07:48.380 --> 07:55.020]  very hard to hack it without understanding how does it work. And so, you can only can try to
[07:55.020 --> 08:01.160]  maybe use fuzzing and other things, and try to understand how does it work. And it is only one
[08:01.160 --> 08:05.920]  way to understand how to hack the bank infrastructure. So, API, it is usual web
[08:05.920 --> 08:14.820]  application, so it can have any web vulnerabilities. So, if I'm talking about the possible
[08:14.820 --> 08:20.260]  vulnerabilities, like I said, it is usual web vulnerabilities. Yeah, it is everything from the
[08:20.260 --> 08:27.320]  OWASP. Yeah, you just can take the checklist of OWASP and any vulnerability and the most related
[08:27.320 --> 08:33.820]  to the server-side. So, also, it is misconfigurations. It can be anything like
[08:33.820 --> 08:43.820]  Nginx misconfigurations, maybe other things. And also, it is logical vulnerabilities,
[08:43.820 --> 08:52.480]  because the bank and the mobile banking, online banking, it is very, very complex thing. Yeah,
[08:52.480 --> 09:01.060]  it has very, very complex architecture. And so, when architecture is complex,
[09:01.060 --> 09:07.220]  developers can do a lot of mistakes in this. And so, it can be any logical vulnerabilities,
[09:07.840 --> 09:19.060]  like, I don't know, leakage of sensitive data of clients. Maybe, if it's correct to say race
[09:19.060 --> 09:27.620]  condition, but it is not logical vulnerability, but sometimes it can be based on logical
[09:30.480 --> 09:40.540]  problems. And other vulnerabilities, it is only example. So, it can be anything.
[09:41.200 --> 09:50.000]  Next one, it is front-end. So, it is user interface. Yeah, based on the data received from
[09:50.000 --> 10:00.400]  API. And so, and because it loads in browser, yeah, browser take a lot of security job on itself.
[10:00.400 --> 10:09.820]  And so, it is very big difference between the mobile application, yeah, and front-end,
[10:09.820 --> 10:15.820]  because browser do a lot of security job by itself. But in mobile applications,
[10:16.540 --> 10:25.900]  developers have to do the things by itself. And possible vulnerabilities, it is XSS, it is,
[10:25.900 --> 10:35.460]  I don't know, DOM-based XSS, it is CSRF, yeah. Maybe forgotten or maybe unfinished pages, yeah.
[10:35.460 --> 10:44.940]  Sometimes, for example, developers make and publish in production React application,
[10:44.940 --> 10:51.700]  but this application has pages that doesn't work and they are invisible for clients.
[10:51.700 --> 11:02.520]  But anyway, they exist in production. And so, after understanding and maybe reversing of
[11:02.520 --> 11:12.700]  React application, yeah, you can find this and you can recover the API methods that
[11:12.700 --> 11:21.040]  application sends to API and gets and it allow you to try more requests and
[11:22.520 --> 11:31.060]  maybe find another vulnerabilities. And also, it can be unsafe communication with API server.
[11:31.840 --> 11:38.020]  And it is everything about the society, it is everything about communication,
[11:38.020 --> 11:43.160]  maybe other algorithms and so on, so on. And again, it is only examples,
[11:43.160 --> 11:47.400]  maybe there are another ones. There are another ones, of course, there are.
[11:48.440 --> 11:56.540]  So, if we're talking about mobile testing approaches, yeah. Like I said, mobile,
[11:56.540 --> 12:06.580]  it is an application, it is like custom-made browser. And in this case, you have a lot of,
[12:07.220 --> 12:15.160]  I don't know, security and customization features, yeah. And so, you have a lot of
[12:15.160 --> 12:22.240]  possibilities to do something wrong. And in this case, possible vulnerabilities, it is
[12:22.240 --> 12:31.040]  storing of sensitive data, yeah. And we will talk about this in one example a little bit later.
[12:31.040 --> 12:35.520]  So, also, it is unsafe handling of external data. And
[12:38.400 --> 12:46.280]  because there is one good example of vulnerability, when mobile application got
[12:47.730 --> 12:55.140]  external data and save it to SQLite database. So, and there was a SQL injection in this.
[12:55.140 --> 13:06.760]  And if you can sniff and if you can edit the traffic that application gets from the network,
[13:06.760 --> 13:11.940]  yeah, you can do the SQL injection on the client side. It is very interesting thing.
[13:12.020 --> 13:19.280]  So, also, it is unsafe work with mobile platform. It is, for example, IPC mechanism and
[13:19.280 --> 13:26.140]  other things, maybe. And also, there are a lot of different things.
[13:26.780 --> 13:32.900]  And let's talk about testing guides, testing approaches for every type of online banking,
[13:34.120 --> 13:40.860]  yeah. For web banking, you know, in this slide, I wanted to set, I wanted to make the big
[13:42.200 --> 13:53.880]  table with comparing of different guides and with choosing the best one. But, no, I just didn't find
[13:53.880 --> 14:00.680]  any other good guides except Avast per Web and Avast per MSTG. So, maybe, you know, and
[14:01.680 --> 14:08.520]  if you use something else, you can maybe share it in comments. So, it is really good because...
[14:11.440 --> 14:19.080]  but for web banking, we also usually use Avast per Web, yeah. It has very good checklist and it
[14:19.080 --> 14:26.220]  has a lot of different vulnerabilities. So, it is really great and good job of someone who made
[14:26.220 --> 14:37.740]  this, yeah, of people who made this. And so, mobile banking, it is Avast per MSTG and Avast
[14:37.740 --> 14:47.080]  Web guides. And Avast per MSTG, it is about everything that's related to mobile platform,
[14:47.080 --> 14:54.340]  yeah, all vulnerabilities that's related to this one. And why Avast per Web here? Because we have
[14:54.860 --> 15:05.900]  service side, yeah, and when we're watching the mobile application, we have to check the platform,
[15:05.900 --> 15:12.920]  the application, and also we have to check the server side and how it communicates with a mobile
[15:12.920 --> 15:19.200]  application. So, for the platform, for the application, we use Avast per MSTG. And for the
[15:19.200 --> 15:30.600]  service side, we use Avast Web. And it has maybe some intersections, yeah. And so, in the best way,
[15:30.600 --> 15:40.300]  this intersection should be fixed, yeah. And the best way is to have that one big checklist
[15:40.300 --> 15:48.340]  and one big guide. And so, using of this checklist is very, very conveniently and
[15:49.370 --> 15:57.020]  it is really helps us to don't forget something when we test it. So, after that, we
[15:59.140 --> 16:05.180]  begin to talk about vulnerabilities. And now it is the biggest part and we will talk about this
[16:06.340 --> 16:14.360]  until the finish of the presentation. And firstly, I want to say why I choose this vulnerability.
[16:15.340 --> 16:19.080]  There are three options and there are three
[16:21.760 --> 16:26.580]  reasons why I choose this. Firstly, it is, for example, some vulnerabilities are very common,
[16:27.190 --> 16:34.040]  you can meet it in a lot of different applications. And it is very common. And
[16:36.700 --> 16:43.900]  this is a problem. So, the second one reason, it is because some vulnerabilities are really
[16:43.900 --> 16:51.900]  interesting. And they are not common. Yeah, maybe it is very rare vulnerability. But anyway,
[16:51.900 --> 16:56.420]  it is really, really interesting. And it is like really hacking. And for example,
[16:56.420 --> 17:01.500]  like I said before, it is like making money from nothing. Yeah. And so on. And so, it is really,
[17:01.500 --> 17:07.800]  really interesting and I love it. And so, the third one reason, it is because sometimes some
[17:07.800 --> 17:13.920]  vulnerabilities are really hard to fix. Yeah. And developers are trying to fix it and make another
[17:13.920 --> 17:20.640]  vulnerability. And so, we will talk about... I don't remember one example of this vulnerability.
[17:20.640 --> 17:27.080]  And so, it... Okay, a little bit later we will talk about it. So, let's begin from the first
[17:27.080 --> 17:34.080]  one vulnerability. And first vulnerability, it is rounding attack. It is currency rounding attack.
[17:34.080 --> 17:42.660]  And it is one of my favorite vulnerability, because it is really, really hacking. Like I
[17:42.660 --> 17:47.240]  said before, and I talk about this vulnerability, it is like making money from nothing. Yeah.
[17:47.240 --> 17:53.960]  And so, first information that I found about this vulnerability, it was 2011, maybe 2012.
[17:54.460 --> 18:02.280]  Maybe there are early information, but I didn't find. So, this vulnerability based on the
[18:03.940 --> 18:13.380]  incorrect or unsafe using of round functions. Yeah. And later we will talk about example.
[18:13.380 --> 18:20.780]  But now, very, very simple example of using of round functions. And it is very simple. But
[18:21.620 --> 18:29.700]  for us, interesting last example, when we can... In round function, we can set what is...
[18:30.740 --> 18:41.000]  We can set the decimal places that will be after rounding. And as you can see on this example here,
[18:41.790 --> 18:53.740]  it is two decimal places after rounding. So, after rounding, we will get 1.52. Yeah. And so,
[18:54.420 --> 18:56.260]  you can say that it is not
[18:58.680 --> 19:04.860]  real vulnerability and it is not possible to meet it in real life. But... And for example,
[19:04.860 --> 19:11.540]  all banks already fixed it and all companies that work with money already fixed it too.
[19:11.540 --> 19:19.820]  And you can't meet it in real life. So, but no, there are examples and you can find it on Hacker
[19:19.820 --> 19:27.560]  One. And I met this vulnerability two years ago and I know one very huge bank. And so,
[19:27.560 --> 19:41.800]  no examples exist. So, let's watch the example. Yeah. For example, we have one account. Yeah. And
[19:41.800 --> 19:49.180]  this account has two wallets, USD and ruble wallets. Yeah. And you can transfer money between
[19:49.180 --> 19:58.380]  these wallets. And when you transfer money, the different currencies convert in between. Yeah. And
[19:58.380 --> 20:07.740]  for example, in this case, we have unreal rates. But anyway, it is very comfortable for us for
[20:07.740 --> 20:17.780]  calculations. So, current rates, it is 64 rubles for one dollar in case of buying. And the same
[20:17.780 --> 20:29.860]  64 one USD in case of selling. And so, we have bank that use rounds into decimal places. Yeah.
[20:29.860 --> 20:38.060]  And our goal is to become rich. So, what we can do? Let's watch the attack. Yeah.
[20:39.840 --> 20:52.360]  We have, one second, we have one ruble on the ruble wallet and we send it to the USD wallet.
[20:52.360 --> 21:01.720]  And after rounding, yeah, firstly, we convert it to the USD. And after that,
[21:02.560 --> 21:13.560]  calls function rounding. And as a result, we will get 0.02 USD from one ruble. Yeah. After that,
[21:13.560 --> 21:21.500]  we convert, we send this two cents back to the ruble wallet. Yeah. And
[21:23.060 --> 21:36.120]  it will be already one ruble and 20. Yeah. And now we have profit 120%. Why it happened?
[21:36.120 --> 21:46.200]  This has happened because of this. This is main reason. So, we had one number and after wallet,
[21:46.200 --> 21:55.440]  it became more. Yeah. And this difference is very critical. So, we can get a big profit.
[21:55.460 --> 22:06.100]  And you can say that now we have two additional ruble cents. Yeah. And it is not rich. Yeah.
[22:06.120 --> 22:14.560]  But if you can repeat it 1,000 or maybe 1,000,000 times, you will get real money.
[22:14.780 --> 22:21.880]  I think banks not allowed to make this a lot of time because anti-fraud and some other things.
[22:21.880 --> 22:29.020]  But anyway, if this vulnerability exists, sometime someone can try to exploit it. And
[22:29.760 --> 22:40.520]  it is, I think, the best way to fix it anyway. So, and I have very simple plot. Yeah.
[22:41.260 --> 22:53.140]  Firstly, on the X, we have transfer amount rubles. Yeah. And the Y, we have profit and the persons.
[22:53.140 --> 23:05.680]  And so, as you can see, the biggest profit when we send about, I don't know, 0.3, 0.4 rubles to
[23:05.680 --> 23:16.600]  the dollars, to the USD. And in this case, the profit is the highest. Yeah. And as you can see,
[23:16.600 --> 23:23.000]  if we send more, yeah, the profit less, less, less. And after some specific moment,
[23:23.000 --> 23:32.900]  it is less than 100. So, it is non-profitable for us. And from this, you can see that it is
[23:32.900 --> 23:38.540]  first way to how to avoid this vulnerability. It is set the limit of transaction. For example,
[23:38.540 --> 23:46.840]  if we'll set the limit of transaction in 6 rubles, yeah, it will be unprofitable for anyone
[23:46.840 --> 23:55.420]  who tried to exploit this vulnerability. So, also, there are two other ways. And
[23:56.460 --> 24:06.260]  second one, it is that we shouldn't allow to clients to convert money from rubles to USD.
[24:06.260 --> 24:20.160]  Instead of this, we should allow to buy USD. Yeah. For example, client will buy 0.01 USD.
[24:20.600 --> 24:31.800]  And after that, client will get price. And after that, they can finish the transaction. So,
[24:32.500 --> 24:39.260]  in this case, anyway, there is rounding. Yeah. And it will be. But in this case,
[24:39.260 --> 24:47.840]  numbers are higher. The numbers are bigger, sorry. And it will be unprofitable for anyone
[24:47.840 --> 24:54.340]  who is trying to exploit this vulnerability. So, and there is another way. It is adding commission
[24:54.340 --> 25:00.680]  after certain number of transaction. It is not looks like good way. But
[25:02.180 --> 25:11.760]  anyway, it works. And so, but it looks like not like good fix. So, but this vulnerability that
[25:11.760 --> 25:18.260]  I found this rounding attack took two years ago, the bank fixed this by adding commission
[25:18.260 --> 25:27.340]  after specific count of transactions. So, another example, it is sensitive data disclosure. It is
[25:27.340 --> 25:34.160]  very common vulnerability that is you can meet in every and a lot of application. Not every,
[25:34.160 --> 25:43.320]  but a lot of. But maybe, maybe in every. I don't know. So, let's watch an example,
[25:43.320 --> 25:49.780]  good example, interesting example. And this example shows that what is convenient is not
[25:49.780 --> 25:58.120]  always safe. So, we should look for balance between convenient and for between security.
[25:58.120 --> 26:06.100]  And it is very important. And case, the bank added functionality that allowed to send money between
[26:06.100 --> 26:17.640]  cards without login procedure. So, it looked like this. So, user enters firstly information about
[26:17.640 --> 26:24.800]  source card, about their card. And after that, user enters the information about the destination
[26:24.800 --> 26:32.620]  card. It is only PAN code. In the first step, we enter the PAN, CVV and expired date. So,
[26:32.620 --> 26:42.520]  on the second, only PAN code. So, on the third step, user enters the amount of money for transfer.
[26:42.860 --> 26:50.540]  And on the next step, system checks the balance and calculates the commission. And if everything
[26:50.540 --> 27:00.500]  is okay, money is enough and so on, user gets SMS. The user that has the source card gets SMS.
[27:01.220 --> 27:07.200]  After entering the code, the transaction is done. If code is okay. So, let's watch
[27:07.200 --> 27:19.520]  into the HTTP request that was used for checking the balance. Yeah. And it was a problem. The
[27:19.520 --> 27:29.840]  main problem was that this server didn't check the expiry date and didn't check the security code.
[27:29.840 --> 27:44.640]  Yes. So, but it checked the money amount and card number. So, as a result, everyone could get balance
[27:44.640 --> 27:51.660]  for any card in the bank. So, just by enumerating the card number and just by enumerating the money
[27:51.660 --> 28:05.240]  amount. So, it worked like if you set too much money, yeah, server will return the error that
[28:05.240 --> 28:14.060]  money is not enough. Yeah. In other case, it will be everything's okay, enter please code. Yeah.
[28:14.060 --> 28:22.920]  Please enter the code. So, and you can set any card number. So, you can get information about
[28:22.920 --> 28:32.060]  every card in bank. And it is not so good. Now, it fixed. Next vulnerability, it is unsafe OTP.
[28:32.760 --> 28:41.340]  Firstly, what is OTP? OTP, it is one-time password. And it is usually one of the most
[28:42.280 --> 28:48.080]  popular realization of second factor. Yeah. For example, you enter to the mobile banking. Yeah.
[28:48.080 --> 28:56.280]  You enter your login and password. And after that, you get the SMS code or maybe push notification
[28:56.280 --> 29:04.880]  or maybe something like this. Yeah. And you have to enter it to pass the second factor of
[29:04.880 --> 29:14.200]  notification. And usually, usually, it deliver it via SMS. Yeah. And it is the most popular way
[29:14.200 --> 29:24.100]  for delivering. So, let's watch an example. Yeah, we are hacker. Yeah. And we got access to
[29:24.100 --> 29:31.220]  user account. And so, we want to get money of this client. So, we have to send this money from
[29:31.220 --> 29:39.840]  our account to the... from user account to our account. Yeah. So, and for completing this
[29:39.840 --> 29:45.980]  transaction, we have to enter the correct OTP. This OTP sends to the mobile of the client
[29:45.980 --> 29:52.920]  and owner of this account. And so, we don't know this OTP. But we have to enter it. And so,
[29:52.920 --> 29:58.740]  after free and correct... and every time when we create a transaction, we have only three tries.
[29:58.740 --> 30:07.800]  After three incorrect entries, transaction will be canceled. And OTP has four random
[30:09.120 --> 30:15.680]  digits. Yeah, digits. And it is, for example, one, two, three, four. Yeah.
[30:17.180 --> 30:23.340]  So, how to make this transaction? How to finish this transaction?
[30:26.040 --> 30:33.240]  It is like a little bit strange. But what if instead of brute-forcing OTP, yeah, we will try
[30:33.240 --> 30:40.100]  to brute-force transactions. Yeah. What if it will be not brute-forcing, but it will be guessing?
[30:40.640 --> 30:47.500]  Sounds strange. I'll explain. Okay. Very important thing. If we're not limited in the
[30:47.500 --> 30:52.580]  number of new transactions, if we can create and create and create and so on, yeah, we can
[30:52.580 --> 31:02.720]  try the next exploitation. We choose three different OTP. Yeah. It should be a potential
[31:02.720 --> 31:09.760]  correct OTP. One, two, three, four, I don't know, five, five, five, five, six, six, six, six. Yeah.
[31:09.760 --> 31:18.840]  And after that, we create new transaction. And try choosing OTP. Yeah. If it isn't correct,
[31:18.840 --> 31:25.500]  to step two and create new transaction. But on this moment, it is, but every transaction,
[31:25.500 --> 31:33.240]  it is regenerate the OTP. So, we can just brute-force it. We can just take the one big
[31:33.240 --> 31:40.660]  dictionary. Yeah. And using this dictionary to enumerate, to brute-force all existing OTP.
[31:40.660 --> 31:48.140]  No, it doesn't work like this. But it is very, very similar. Yeah. So, and we should repeat this
[31:48.140 --> 31:56.400]  algorithm, this exploitation until we matched at least one OTP. If we matched at least one OTP,
[31:56.400 --> 32:03.320]  the transaction will be finished. Yeah. And so, it is one big difference. It looks like brute-force,
[32:03.320 --> 32:09.940]  but it isn't brute-force. It is guessing. So, in case of brute-force, we know about when it
[32:09.940 --> 32:17.780]  will be finished. For example, dictionary has size 10,000 lines. So, it will be finished after
[32:18.400 --> 32:26.980]  trying of 10,000 lines. So, in case of this brute-force, yeah, but it is guessing.
[32:27.220 --> 32:32.860]  We're not sure when it will be finished. It can be finished on the next transaction,
[32:32.860 --> 32:40.020]  or it can be finished after 20,000 transactions. Yeah. We're guessing. We're trying to enumerate
[32:40.020 --> 32:53.980]  transactions. Yeah. Until the generated OTP didn't match our OTP. So, I'll explain everything.
[32:54.520 --> 33:01.860]  No, I'm joking. I am not going. It is boring. So, no, no, no. But it is very interesting results.
[33:01.860 --> 33:06.880]  Let's watch the results. So, probability of the successful transaction depends on the
[33:06.880 --> 33:15.100]  number of attempts. So, in our guessing exploitation, yeah, after 3,000 attempts,
[33:15.100 --> 33:23.620]  then it will be about 60% probability. Yeah. But if we can try 16,000 attempts,
[33:23.620 --> 33:34.980]  it will be 99%. So, it is a really good result, I think. And let's watch a little bit more
[33:35.720 --> 33:42.160]  complex example with new limitations. The same example, totally the same OTP,
[33:42.160 --> 33:48.740]  totally the same situation, and so on. But after five canceled transactions, we can't create a new
[33:48.740 --> 33:56.200]  one. We will be blocked for several times. For example, for 24 hours. Yeah. And so, what we can
[33:56.200 --> 34:04.840]  do in this case? There are two possible approaches. First approach, it's totally the same
[34:04.840 --> 34:16.600]  exploitation, totally the same steps, but we try not three OTP for each transaction, but two OTP.
[34:16.600 --> 34:25.120]  So, in this case, we avoid the cancellation of transaction. And in this case,
[34:25.120 --> 34:31.820]  creation of transaction will not be blocked. Yeah. So, it is one approach. Another one,
[34:31.820 --> 34:36.640]  we can, in the beginning, create several thousands of transactions. Yeah. For example,
[34:36.640 --> 34:42.260]  we can create 20,000 of transactions, and only after that, we will try the OTP.
[34:42.280 --> 34:49.100]  So, in this case, yeah, we will block the creation of new transactions after trying the OTP. Yeah.
[34:49.100 --> 34:57.460]  But it is not affected. It doesn't affect us, because we already created the 20,000. And
[34:58.020 --> 35:05.080]  as you can see from the calculations, in case of 20,000, it will be more than 99%
[35:05.840 --> 35:18.700]  probability of success. So, we will get profit. So, and also,
[35:18.700 --> 35:28.180]  very good question. Is SMS a secure way of OTP delivery? Yeah. It is a good question,
[35:28.180 --> 35:34.980]  because there are a lot of attacks against the SMS. It can be fake BTS. It can be
[35:34.980 --> 35:41.420]  ratio of SIM card. It can be SS7 attacks. Yeah. For example, these two very
[35:45.700 --> 35:53.480]  cheap things, it can be used for creating the fake BTS, for creating the fake station. Yeah.
[35:53.480 --> 36:10.440]  And using this, you can try to attack the client. So, let's talk about the recommendations. Yeah.
[36:10.440 --> 36:17.560]  Firstly, second factor should be enabled for all critical actions. Yeah. If you, for example,
[36:17.560 --> 36:28.120]  login to account, if client, for example, logins to account, for example, if changes the profile
[36:28.120 --> 36:38.420]  information, maybe other critical actions, it should be, client should enter the second factor.
[36:38.420 --> 36:46.520]  Also, it is very important to limit the count of requested OTP. On the previous examples,
[36:46.520 --> 36:54.140]  we tried to limit the creating of transactions, but sometimes it is a little bit hard. Maybe
[36:54.140 --> 37:01.570]  you can make another vulnerability and so on. So, the best way is to control the OTP.
[37:01.570 --> 37:11.590]  So, how many OTP, how many generation of OTP client asked. Yeah. And after specific count,
[37:11.590 --> 37:21.250]  just stop this process. And also, maybe it is a good way to think about alternative for SMS,
[37:21.250 --> 37:29.230]  because SMS not looks like the best way for delivering OTP. For example, we can watch on
[37:29.230 --> 37:36.750]  the push notification, we can watch on the TOTP and HOTP. TOTP and HOTP, it is, for example,
[37:36.750 --> 37:40.630]  Google notification, it is Microsoft notification. It is applications that you
[37:40.630 --> 37:59.210]  have on your mobile phone and they use cryptography for OTP process. So,
[37:59.210 --> 38:11.430]  it is totally silent because it doesn't have delivering. Yeah. So, client doesn't know about
[38:11.430 --> 38:21.530]  that someone trying to brute force its second factor. Yeah. And so, sometimes it is very
[38:21.530 --> 38:28.090]  critical because in case of SMS or maybe push notifications, client will get a lot of messages
[38:28.650 --> 38:35.530]  about that and understood that something's wrong and maybe call to support and support will call
[38:35.530 --> 38:44.890]  to security information specialists. And so, maybe attack will be stopped. But in case of TOTP and
[38:44.890 --> 38:54.690]  HOTP, it doesn't look like this. Next vulnerability, it is unsafe randomization.
[38:55.970 --> 39:03.210]  And it is, you can meet it in application where logic is based on the generation of
[39:03.210 --> 39:14.490]  random values. It can be sessions, it can be OTP, maybe unique identifiers. Yeah. And it is,
[39:15.590 --> 39:22.810]  for example, most common problems, it is using of unsafe predictable
[39:24.370 --> 39:28.870]  random numbers generators. Yeah. In other case, it can be, for example, using the predictable
[39:28.870 --> 39:37.070]  functions for creating, for example, sessions, maybe unique identifiers and so on. So, in a case
[39:37.070 --> 39:47.710]  when attacker can recover the sequence of random values. Yeah. And it can be in case,
[39:47.710 --> 39:53.430]  for example, incorrect initialization of random number generator and so on. And
[39:56.010 --> 40:03.190]  it is one very known example when... it isn't online banking, of course, but anyway,
[40:03.190 --> 40:11.010]  Russian engineer, they... but it wasn't one engineer, it was team. Okay, never mind.
[40:12.770 --> 40:19.430]  A team of Russian engineers, so maybe one engineer, reversed the slot machine. Yeah. And
[40:19.430 --> 40:29.150]  they recovered the sequence. They recovered it of algorithm, how it used randomization. Yeah.
[40:29.150 --> 40:37.350]  And they developed their program. I don't know what they did, but they, for example,
[40:37.350 --> 40:45.410]  they developed a program that helped to recover this sequence. For example, they came to the
[40:45.410 --> 40:54.630]  slot machine. They played for several minutes. And in these several minutes, they got the sequence
[40:54.630 --> 41:04.330]  what slot machine showed to them. Yeah. And using this information, they recovered them all sequence
[41:05.150 --> 41:13.810]  of random. And they can... and they know what will be in the future. And so, using this cheat,
[41:13.810 --> 41:21.250]  they can... they did a lot of money. And so, it is one of the good examples.
[41:21.250 --> 41:31.990]  And so, another one good example, I heard from Timur Inusov. And he met... it is on his project.
[41:31.990 --> 41:45.730]  So, for OTP generation was used LCG generator, yeah, for randomization. So, but using of LCG
[41:45.730 --> 41:55.870]  is not okay, because it is not cryptography safe. And for example, when you have a sequence of
[41:55.870 --> 42:03.130]  several generated codes, you can recover all sequence. So, you can predict next OTP codes.
[42:03.370 --> 42:11.670]  And for OTP, it is very critical. So, something like this.
[42:12.550 --> 42:19.070]  Another vulnerability, it is mobile banking identification. Yeah, it is not vulnerability,
[42:19.070 --> 42:27.710]  but it is like evolution, yeah, for mobile banking identification. I'll explain, okay.
[42:27.710 --> 42:36.670]  For example, we have case. Client installed our mobile banking application on the mobile phone,
[42:36.670 --> 42:44.950]  and client, very good client, yeah, you know, they know a lot about security. And
[42:46.590 --> 42:54.830]  so, client has very strong password, yeah. And on the mobile phone, and the very strong
[42:54.830 --> 43:04.550]  password is not convenient, yeah, and it's not so comfortable. And so, our task is to
[43:05.790 --> 43:11.950]  develop the simple authentication process, and that works after first login. For example,
[43:11.950 --> 43:18.390]  first time a user enters their login and password. After that, something happens,
[43:18.390 --> 43:24.470]  and user can enter there more simply. Yeah, for example, using PIN code or something like this.
[43:24.470 --> 43:33.390]  And so, let's try to make this solution, yeah. Firstly, what is the most simple way?
[43:33.390 --> 43:40.990]  After entering the login and password, the application just save the user password to file,
[43:40.990 --> 43:45.330]  and every time when the user opens the application, the application sends the
[43:45.330 --> 43:55.070]  password to the server and get the session, the live session. It is awful. It is totally unsafe.
[43:56.770 --> 44:02.650]  Because of the saving of password, it is awful practice by design.
[44:02.650 --> 44:09.510]  Do not do this. It is awful. The second problem that unlocked device provides access to mobile
[44:09.510 --> 44:18.490]  functions. So, anyone who can get access to unlocked device, or maybe device
[44:19.770 --> 44:31.130]  doesn't have PIN code because it didn't set. Yeah. So, in this case, anyone can just use
[44:31.130 --> 44:38.510]  the mobile one. It isn't okay. And so, finding the second factor doesn't help in this case,
[44:38.510 --> 44:47.150]  because this phone has the SIM card, and the SMS will be on this phone. So,
[44:47.150 --> 44:54.210]  and the third one, the hacker can get access to the file with password, yeah. And in case,
[44:54.210 --> 45:00.310]  for example, if application has vulnerabilities, yeah, or just because of hacker has
[45:00.310 --> 45:09.090]  hacked the phone and now has root access. And in this case, hacker can just open any file on the
[45:09.090 --> 45:19.510]  file system, almost. So, another case, after successful login, yeah, user sets the PIN code.
[45:20.030 --> 45:28.430]  Yeah, and PIN code saves, or maybe not saves, but it uses it by checking the access by application,
[45:28.430 --> 45:37.350]  and for example, now we use refresh token, yeah. And I forgot to say that the best practice,
[45:37.350 --> 45:44.890]  save not password, but save the refresh token, yeah, and using the refresh token for creating
[45:45.050 --> 45:54.530]  a live session. So, after first login, yeah, user set PIN code. This PIN code used for decrypting
[45:54.530 --> 46:04.430]  encrypted refresh token, yeah. So, and also, this PIN code used for checking the access. So,
[46:04.430 --> 46:12.250]  you open the mobile application, you enter the PIN code, PIN code, for example, comparing with
[46:12.250 --> 46:16.890]  something, yeah, and for example, decrypting the refresh token, the refresh token sends to server,
[46:16.890 --> 46:30.870]  and server backs a live session, yeah. Again, it is an awful realization, because firstly,
[46:30.870 --> 46:36.670]  anyway, we store the refresh token in the file, so hacker, again, if there are vulnerabilities,
[46:36.670 --> 46:45.050]  or if hacker have root access on the mobile, hacker can just get access to file with password.
[46:45.050 --> 46:53.170]  In another case, encryption of token with short PIN code is useless, because PIN code is very short,
[46:53.170 --> 47:02.970]  and brute force of this will be very fast. And also, any local checks, like PIN code check,
[47:02.970 --> 47:10.310]  and other things can be easily bypassed by Frida, if you have enough access on the device.
[47:10.310 --> 47:18.150]  So, it doesn't work like this. So, next realization, we save refresh token to the
[47:18.150 --> 47:30.290]  kstore kchain, yeah. And you know, kstore kchain is the very good option, but it is unsafe only
[47:30.290 --> 47:40.090]  in one case, when we enable the checking of biometric open code, when someone opens this
[47:40.090 --> 47:46.430]  record. In this case, hacker can't get access to these records in kchain. In another case,
[47:46.430 --> 47:55.390]  if no access checking, and the application just extract the data from kchain kstore without any
[47:57.590 --> 48:04.410]  interactions with the user, in this case, it is totally unsafe. Not totally, but unsafe, because
[48:04.410 --> 48:12.950]  of a hacker with root access can just extract it without any problems. So, also, it can be
[48:12.950 --> 48:21.890]  problematic if a user has old device. And in this case, maybe problems with kstore kchain,
[48:21.890 --> 48:31.770]  maybe just device don't have enough security functions, and so on. And also, but it is very
[48:31.770 --> 48:37.590]  similar to the second one, and the third one, is that you completely dependency on the kstore
[48:37.590 --> 48:46.050]  kchain security. So, if there are some problems with this, you have problems with the application.
[48:46.920 --> 48:55.750]  And the last one realization, application asks user to set pin code, and this pin code will be
[48:56.530 --> 49:07.330]  sent to API. So, API controls the identification process. And in this case, you can control
[49:08.250 --> 49:14.730]  anything, like brute force, like enumeration, and other things. So, you can control anything.
[49:14.730 --> 49:21.790]  In this case, it is totally the same. For example, in case of using kstore kchain,
[49:22.570 --> 49:30.250]  user can't use any pin code, because it will be a pin code of device only. In case of the last
[49:30.250 --> 49:37.560]  realization, user can use any pin code, because it is no limitation. And we can set, for example,
[49:37.560 --> 49:46.420]  ask for the big pin code, like six symbols, maybe eight symbols, any pin code, and other things.
[49:47.900 --> 49:55.480]  But it is very important, too, that now we have to protect our server-side, because
[49:55.480 --> 50:02.820]  everything depends on our server-side. That's all that I wanted to show you.
[50:02.820 --> 50:10.940]  So, now about conclusions. Firstly, there are good testing guides. There are good testing
[50:10.940 --> 50:17.000]  approaches. And you can use it not only for testing the applications, but you can use it for
[50:17.000 --> 50:24.400]  developing the application, for making applications. And it is really useful. It
[50:24.400 --> 50:31.420]  has a lot of examples, and so on. Also, the next conclusion is sometimes convenience is the enemy
[50:31.420 --> 50:40.300]  of security. And as you can saw from the example, yeah, third example with bank that added the
[50:40.300 --> 50:46.740]  functionality of sending money between cards without login. It is sometimes too critical,
[50:46.740 --> 50:51.700]  yeah. And so, it is very important to find the compromise between convenience and
[50:52.300 --> 50:58.920]  between security. Next one, it is be careful with cryptography, randomizations, and other things,
[50:58.920 --> 51:03.720]  because cryptography is really complex, and it is very important to understand what you do.
[51:03.720 --> 51:11.220]  And just don't use cryptography without understanding. It is bad practice. And the
[51:11.220 --> 51:20.540]  last one conclusion is use best practices, and use experience of other companies. Watch on other
[51:22.040 --> 51:32.040]  products, watch on other applications, because a lot of problems, yeah, and some companies
[51:32.720 --> 51:41.140]  already solved these problems. And if you find the correct solution, it will be very good.
[51:41.500 --> 51:49.700]  And so, it is everything that I wanted to say. So, thank you for attention. I hope
[51:49.700 --> 51:54.720]  you got something new from this presentation. Thank you.
